IBIS Macromodel Task Group Meeting date: 02 April 2019 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Cadence Design Systems: Ambrish Varma Brad Brim Kumar Keshavan Ken Willis eASIC: David Banas GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: * Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki * Ming Yan Stephen Slater Maziar Farahmand Mentor, A Siemens Business: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft (Mathworks): * Walter Katz * Mike LaBonte SPISim: * Wei-hsing Huang Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Walter to send out the modified draft response for further review by those in attendance. - Done (to be reviewed in this meeting). -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the March 26 meeting. Bob moved to approve the minutes. Mike L. seconded the motion. There were no objections. ------------- New Discussion: Draft response to the authors of BIRD198: Mike L. shared the modified draft response email. Arpad, Bob and Mike L. noted that some of the simplifications and deletions discussed in the previous meeting meeting were not reflected in the email. Bob noted that many of the issues he raised in his response would have been addressed already by the previous meeting's changes. Mike L. and Bob took the AR to go over the previous week's minutes and fully revise the original draft according to those discussions. Arpad suggested we wait until the next meeting to continue discussions. There were no objections. Arpad noted that we had no new updates on the remaining agenda items: Enhanced C_comp and DDR5 issues. Michael M. asked to discuss an issue he had raised in an email "Technical questions on BIRD197.2" sent to ATM on March 27, 2019. Question about DC_Offset: Michael noted that he had gotten some feedback from model makers on BIRD197.2. He said there was some confusion about the fact that DC_Offset was a parameter of Usage In, but the value provided in the .ami file is a throw-away place- holder and the value comes from the tool not the user. He asked if we should add a diagram or additional explanation. Arpad said he thought the confusion might stem from that fact that we have so many possible directions for AMI parameters. Some parameters are provided for the tool (Info), some go into the model (In), some come back from the model (Out), and there is also information passed around between the tool and the AMI DLL through the AMI function arguments. The sticky point might be that we didn't define a crisp way of conveying the direction information. Radek noted that the issue is related to the function signatures in the model (.dll). If a model doesn't have the AMI_Resolve() function, then everything has to go through the AMI parameters, Reserved or Model Specific. He noted that we already have some Reserved parameters that are placeholders in the AMI file. Arpad noted that DLL_Path is analogous. Mike L. agreed and noted that the tool, not the user, typically provides the value for DLL_Path as is the case for DC_Offset. Mike L. noted DLL_ID as well. So, the concepts applied to DC_Offset are not new. Mike L. noted that we have some AMI parameters for which the values are provided by the user and some for which the value comes from the tool. Michael asked if we could add an editorial clarification (diagram, table, etc.) that captured what Mike L. had said. Arpad asked if there was anything in the Definition:, Usage Rules:, etc., for DC_Offset that left it unclear? Michael M. noted that it can be tough to expect model makers to review the entire spec. Arpad asked if adding any editorial clarification would help. If we add a new table, are people going to read it? Michael M. agreed to work on drafting a BIRD to propose the type of clarification he felt would be helpful. He noted that it would not happen quickly. Parsing IBIS-ISS files: Mike L. brought up an issue from the Quality Task Group. He noted that there have been occasional discussions in the past about whether we should develop an official parser for the IBIS-ISS. Typical questions are: - Would it be a separate program or part of ibischk? - Would it parse such that it created structs in memory and could be used as a front end (for source code purchasers)? - Would it check for connectivity and other issues or just basic syntax? Mike noted that the Quality Task Group largely consists of Mike, Bob and Lance. Therefore, it doesn't have a representative set of opinions. Arpad asked how important an issue this was and noted that every tool has some sort of SPICE engine. So, the model maker would not be left without any information about any problems in the IBIS-ISS model. Randy asked if, for a given tool, you can be sure you're really checking for what's allowed in IBIS- ISS, or are you accepting a broader set of functionality? Arpad agreed that most tools would allow a superset of IBIS-ISS capabilities. Michael M. noted a strong belief that we need a generic IBIS-ISS parser. He noted that: - We can't assume everyone has access to a compatible tool. - Not all tools are equal and would include the same features. - The value of the IBIS parser is that it's the official arbiter of what is valid. - It provides a single standard reference. - We want to allow model makers to be sure they've produced a minimally compliant model. Randy noted that Justin had produced some examples of IBIS 7.0 compliant models using different interconnect models aligned with BIRD197. However, they really have no idea whether their IBIS-ISS files are compliant. From their perspective a parser would be very helpful. Mike L. noted that making sure the IBIS-ISS file only contained the proper subset of SPICE components would be the primary value of a parser. Mike also noted that we now have Touchstone files used in IBIS. We have a separate tschk2 for checking those files, but it's a separate program and ibischk does not automatically check Touchstone files. He felt that ideally ibischk would check as much as possible. Arpad noted that checking Touchstone files would be nice, but since they can become huge it could be a performance bottleneck. We would probably want a command line option to enable or disable checking Touchstone files. Arpad asked if Bob would discuss an IBIS-ISS parser with the ibischk parser developer. Bob said Michael M. or someone who wants the parser would have to provide some sort of spec. Arpad asked if the IBIS-ISS spec itself isn't the parser spec.? Bob said you need to define what you want that parser to do. Walter said it's a question of syntax checking vs. context checking. A basic syntax check could look at element by element syntax. Context checking would be at another level and might include, floating nodes, proper subcircuit node count, illegal values, etc. Arpad said that if the purpose is to ensure the model stays within the IBIS-ISS subset, then basic syntax checking should be enough. It doesn't guarantee a functional model, but would it be enough to start with syntax checking and evolve over time if necessary? Randy noted that ibischk itself evolved that way. Mike L. noted that ibischk source code purchasers just about fund the cost of the parser development. However, he noted that an IBIS-ISS check would involve separate cost and the overhead of separate contracts, regression tests, etc. He noted that he expected the number of purchasers of the IBIS-ISS parser source code would be small, and he doubted source code sales would fund its development. He noted one way to fund it might be to increase the cost of the ibischk source code. Arpad noted that we could continue this discussion next week. Michael M. noted that this was a bin list topic for Interconnect, but that it could be taken up in ATM instead. Mike L. said the discussion had been helpful. - Mike L.: Motion to adjourn. - Radek: Second. - Arpad: Thank you all for joining. AR: Mike L. and Bob to produce a revised draft response to the BIRD198 authors. ------------- Next meeting: 09 April 2019 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives